The combination of gcc 9.4 and gdb 9.2 in Ubuntu 20.04 have a few
minor test issues that seem to be bugs in gdb that have been since
fixed.

Part of eclipse-cdt#816

The tests were relying on specific number of executable lines
in a function. However on some gdb/gcc combinations stopping
at a function stops at the line with the `{` and some
on the first line witin that function. Much of the tests
here assumed that latter. By using line tags we don't need
to worry about exact number of executable lines between entry
and area of interest. And by placing first line of code on
the same line as the opening `{` of the function, we can
have consistent stop locations when stepping into a function.

Part of eclipse-cdt#816

Without the return, this code would core dump, depending
on compiler version. The compiler was generating a warning
too about the missing return.

Part of eclipse-cdt#816

From GDB news:

print
  Printing of floating-point values with base-modifying formats like
  /x has been changed to display the underlying bytes of the value in
  the desired base.  This was GDB's documented behavior, but was never
  implemented correctly.

This commit updates the tests to accomodate GDB's change.

Fixes eclipse-cdt#210

This test sometimes hangs when run a lot. As best as I can tell this
is a Ubuntu problem, rather than a gdb problem as it only fails on
Ubuntu 24.04, but I am not sure. I cannot reproduce the problem
when using the UI.

Part of eclipse-cdt#816

"script" field of a breakpoint used to be output as a tuple (<= GDB 12),
though it is a list. There are cases of flags that can be applied to
get old or new behaviour too.
This code handles both cases transparently.
See https://sourceware.org/bugzilla/show_bug.cgi?id=24285

Part of eclipse-cdt#816

We should explicitly set the version of mi to use. Until recently
mi == mi2, but with the recent introduction of mi3 as the default
we need to be explicit.

The other place that specifies interpreter is explicit about version
and includes an important comment on the subject

https://github.com/eclipse-cdt/cdt/blob/1590791e76a58ead4d2d7481a5e9a0ff5f83dfab/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBBackend.java#L189-L191

Part of eclipse-cdt#816

On GitHub I see fails in resume[gdb] (org.eclipse.cdt.tests.dsf.gdb.tests.MIRunControlTest)

with this output:

```
Terminate failed
org.eclipse.debug.core.DebugException: Terminate failed
	at org.eclipse.debug.core.Launch.terminate(Launch.java:300)
	at org.eclipse.cdt.dsf.gdb.launching.GdbLaunch.terminate(GdbLaunch.java:313)
	at org.eclipse.cdt.tests.dsf.gdb.framework.BaseTestCase.doAfterTest(BaseTestCase.java:662)
	at org.eclipse.cdt.tests.dsf.gdb.tests.MIRunControlTest.doAfterTest(MIRunControlTest.java:133)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
	at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base/java.lang.Thread.run(Thread.java:1583)
Contains: Terminate failed
Contains: Terminate failed
790,475 "resume[gdb]" requesting gdb. Launched gdb 15.0.50.20240403.
```

which is insufficient to diagnose what is happening.

Part of eclipse-cdt#816

The DSF-GDB tests themselves can take an hour or so.

Part of eclipse-cdt#816